Existing Third Generation Partnership Program (3GPP) universal terrestrial radio access networks (UTRAN) 100, such as a wideband code division multiple access (WCDMA) network or a universal mobile telecommunications system (UMTS) network, depicted in prior art FIG. 1, split the UTRAN 102 into two entities. The first entity is a Radio Network Controller (RNC) 104 and the second entity is a node-B 106. The RNC 104 controls the node-B 106 devices to which it is connected by providing radio resource management and a portion of the mobility management functions. The RNC 104 also provides data encryption/decryption services to protect the user data from being compromised while in transit to and from the user equipment (UE) 108. The node-B 106 provides the transmitter and the receiver for communicating with the UEs 108 within the defined area of the cell. In order to facilitate the handover of a UE 108 from one node-B 106 to another node-B 106 under the control of a different RNC 104, as the UE 108 changes geographical location, the RNCs 104 must communicate with both the core network 110 and the neighboring RNCs 106.
In contrast to the 3GPP UTRAN 100 of FIG. 1, the Long Term Evolution (LTE) based evolved universal terrestrial radio access networks (EUTRAN) 100 architecture, depicted in prior art FIG. 2, has removed the RNC 104 from the LTE network. The functionality of the RNC 104 has been distributed to both core network elements, such as the Mobility Management Entity (MME) 202, and the evolved node-B (eNB) 204. In a complicating factor, the introduction of a portion of the RNC 106 functionality into the eNB 204 has resulted in the requirement for new inter-eNB interfaces 206 and complex hand-off signaling protocols for exchanging information between eNBs 204 as the UE 108 moves around a cell and transitions from one eNB 204 to another.
Further, the traditional LTE radio access network (RAN) is comprised of distributed eNBs 204 connected to MMES 202/serving gateways (S-GW) entities via the S1 interface 208 with the eNBs 204 connected to each other with the X2 interface 206. The LTE eNB 204 hosts functions to support Transport and Control (T&C) capabilities such as Radio Resource Management (RRM) (i.e., radio bearer control, radio admission control, connection mobility control and dynamic allocation of resources to UEs 108 in both uplink and downlink), Internet Protocol (IP) header compression and encryption of user data stream, selection of MME 202 at UE 108 attachment when no routing to an MME 202 can be determined from the information provided by the UE 108, routing of user plane data toward the S-GW 202, scheduling and transmission of paging messages originating from the MME 202, scheduling and transmission of broadcast information originated from the MME 202 or Operations and Maintenance (O&M) and measurement and measurement reporting configuration for mobility and scheduling.
As depicted in prior art FIG. 3 of existing 3GPP eNB 302 functions 300, the eNB 302 embodies the T&C functions required by an LTE network such that a common shared UTRAN 102 RNC 104 is not required. Specifically, the eNB 302 includes Radio Resource Control (RRC) 304 functions for managing mobility and radio resources for the UEs 108 in the eNBs 302 cell coverage area and Packet Data Coverage Protocol (PDCP) 306 functions to provide L3 services to the lower layers for user and control plane messages. Examples of the L3 services are in-sequence delivery of data including duplicate detection and elimination, user plane IP header compression and ciphering of user and control plane data and integrity protection of user and control plane data. Each eNB 302 traditionally supports a small number of cells that cover a tightly coupled geographical area. The cell count per eNB 302 is usually limited, e.g., three cells per eNB 302 and the RRC 304 and PDCP 306 functions embedded in the eNB 302 are limited to supporting the cells controlled by the eNB 302 and the UE 108 associated with those cells.
Problems associated with the previously described architectures are magnified by the projected growth in the use of these services. Wireless broadband traffic is projected to more than double every year for the foreseeable future. Keeping pace with this growth will require a proportional increase in the number of cells in any given geographical area. With the introduction of LTE advanced features to support heterogeneous networks and the requirement for a larger number of cells, the number of cells in a given geographical area is expected to increase over one hundred times with the number of inter-cell mobility events increasing proportionally.
Another emerging problem associated with an eNB 302 providing mobility management functions is the evolutionary trend of network deployments which include Multiple Radio Access Technology (Multi-RAT), i.e., mobility between different radio access technologies such as WCDMA, WiFi and CDMA. The issue arises because the LTE eNB 302 architecture includes mobility management functions. As a result, part of the mobility coordination is distributed at the eNB 302 level requiring the eNB 302 to be aware of each of the hardware technologies.
Another issue related to problems with the existing architecture associated with increasing cell density is the number of user context (e.g., security keys, Robust Header Compression (ROHC), RRC 304 and session state) transfers between eNBs 302 increase as the number of mobility events increases. The successful and time sensitive of this data is critical for maintaining user sessions while the UE 108 is from one eNB 302 coverage area to another. Failure to meet the transfer requirements results in dropped calls or sessions. However, meeting this requirement is complex and error prone and engineering a RAN to provide the necessary high levels of mobility performance requires a relatively static network and significant operational overhead. LTE networks, however, are now in a growth portion of their lifecycle so consequently, maintaining mobility performance in networks that are inherently non-static will be problematic and expensive for network operators. Further, MME/S-GW nodes 202 are currently architected to handle a relatively limited number of S1 interfaces. Consequently, these nodes will struggle to perform efficiently with one hundred times the number of eNBs 302 deployed.
As depicted in prior art FIG. 4, the interface 410 between the PDCP 406 and the RLC 408 is defined as an internal software interface associated with an eNB 402. Accordingly, there is no protocol or transport specified for this interface, i.e., there is no way to distribute the RRC 404 and the PDCP 406 functions outside of the eNB 402. It should be noted in the depicted prior art eNB 402 that the interfaces between the functions are not defined by the 3GPP specifications and no mechanism exists allowing the functions to be located in physically separate network elements.
Market pressure is building for a solution that performs efficiently under the previously described conditions allowing better network performance with lower operating costs and a greater reliability compared to previously described solutions.